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ABSTRACT 



An improved method and apparatus for embedding a real- 
time multi-tasking kernel in a non-real-time operating sys- 
tem is disclosed, Through encapsulating a real-time kernel 
into the interrupt handling environment of a non-real-time 
operating system, such as Windows®, the method of the 
present invention allows for an entire real-rime environment 
to be supported within the operating system. The scheduler 
of the real-time kernel supports multiple threads of execu- 
tion all running at higher priority than the application tasks. 
By using synchronization mechanisms of the operating 
system, e.g. VxD events in enhanced mode Windows®, the 
real-time tasks are able to make use of system services of the 
operating system. Real-time tasks not requiring system 
services execute more quickly from interrupt mode. Real- 
time tasks requiring system services execute partially from 
interrupt mode and partially from event mode. 

14 Claims, 7 Drawing Sheets 




12/14/2001, EAST Version: 1.03.0001 



U.S. Patent May 11,1999 sheet 1 of 7 5,903,752 



Read data from disk 



10 



Transfer memory 
buffer to playback 
device 



I 



12 



Signal task to refill 
the memoy buffer 



14 



Read more data 
from disk 



Fig. 1 



12/14/2001, EAST Version: 1.03.0001 



U.S. Patent 



May 11, 1999 



Sheet 2 of 7 



5,903,752 



20 



Windows 
Applications 



22 



DOS 
Virtual 
Machines 



24 



RT 
Scheduler 



T Interrupt 
Handler 



32 



RT 
Tasks 



34 



Initialixation 
Code 



RT 
Event 



36 



n 

88 



28 



Enhanced Mode Kernel (VMM) 

C 



•26 



CPU 



Fig. 2 



12/14/2001, EAST Version: 1.03.0001 




12/14/2001, EAST Version: 1.03.0001 



U.S. Patent 



May 11, 1999 



Sheet 4 of 7 



5,903,752 




RTTaskl 
Interrupt Mode Processing 
-410- 




Handle the Interrupt processing without 
VM calls. 
-412- 



Yes-416 




No -414 



FIG. 4 




RT Task 2a 
Interrupt Mode Processing 
-510- 




Process Interrupt up to the point where a 
VM call Is necessary. 
-512- 



I 



Can Make.Safe to create a safe 
execution environment for the VM call. 
-514- 



I 



CTo Figure 8 ^"N 
(block 812)^/ 



FIG. 5 



12/14/2001, EAST Version: 1.03.0001 



U.S. Patent 



May 11, 1999 



Sheet 5 of 7 



5,903,752 



CMake.Safe 
Processing Logic 
-610- 




Schedule RT Event to signal a semaphore 
when the execution environment is safe 
-612- 




Yes - 618 



Execute RT Task 2b 
(the continuation of interrupt mode RT 
Task 2a) from event mode. 
-620- 




Fig. 6 



12/14/2001, EAST Version: 1.03.0001 



U.S. Patent 



May 11, 1999 



Sheet 6 of 7 



5,903,752 




RT Event 
Event Mode Processing ) 
710- J 



Signal Semaphore to enable remaining 
RT task processing. 
-712- 




Fig. 7 



RT Task 2b 
(Continuation of processing from Figure 
5 (block 514) 
-810- 



Execute the VM Call(s) 
-812- 



Perform remaining processing for interrupt 

from event mode. 
-814- 




No - 620 




Yes • 822 




To Figure 5 
(block 510) 
-816- 




Fig. 8 



12/14/2001, EAST Version: 1.03.0001 



U.S. Patent 



May 11, 1999 



Sheet 7 of 7 



5,903,752 



RTTASK 



Interrupt 
Mode 



Interrupt 
Processing 



Make_Safe 



Event 
Mode 



^910 

f Execute 
^ VM Call 



Event Mode 
Processing 



Wait for 
next interrupt 
signal 



Fig. 9 



12/14/2001, EAST Version: 1.03.0001 



5,903,752 

1 2 

METHOD AND APPARATUS FOR natural data types, without allowing other operations to 

EMBEDDING A REAL-TIME MULTI- disrupt the delivery and playback of the audio and video 

TASKING KERNEL IN A NON-REAL-TIME data. 

OPERATING SYSTEM The above referenced patent application describes a 

5 method and apparatus for embedding a real-time multi- 
This is a continuation of Ser. No. 08/350,415 which was tasking kernel into a non-real-time operating system. In the 
filed Dec. 6, 1994, now abandoned which is a continuation- described embodiment, all tasks under the real-time kernel 
in-part of Ser. No. 08/323,044 filed Oct. 13, 1994, now U.S. run at virtual machine manager (VMM) event time. When- 
Pat. No. 5,721,922. CVC r an interrupt handler wakes up a blocked task, actual 
BACKGROUND OF THE INVENTION 10 cxecution of me lask * delayed until the VMM schedules an 

event. The task then executes at VMM event time. 

HELD OF THE INVENTION The embodiment described in the above-referenced patent 

The present invention relates to the field of real-time application may experience unnecessary delays in the execu- 

multi-tasking. More particularly, the present invention 15 ^ on °f real-time tasks in some circumstances. Because 

relates to an improved method and apparatus for embedding real-time tasks are always delayed until VMM event time, a 

a real-time multi-tasking kernel in a non-real-time operating certain level of real-time response is comprised. It may not 

system. always be necessary to delay real-time tasks in this manner. 

BACKGROUND OF THE INVENTION 111 im P rovcd method ™ d apparatus for embedding 

a real-time tasking kernel into a non-real-time operating 

Video conferencing and personal computer (PC) applica- system is needed, 
tions which deal with communications and natural data 

types, Le., audio and video data, require real-time interrupt SUMMARY OF THE INVENTION 

handling and task scheduling. Tne user will hear clicks and ^ t invcmion provides m ^ d mcthod ^ 

pops from auoao data output and see modulating or jerky £, for cmbcddiD / a rcaj4imc ^.tasking kernel 

videooutoul,if^ 25 g a * d ^.Tto^^SpS 

audio or video data. Furthermore, playback of audio and mg a kcmcl P int0 * Lrrupt handlingSn- 

natural ^hronized with each other to appear mcnt of a ^^j.^ ^ phicii J, mter ££ such „ 

___ ' t Windows®, the method of the present invention allows for 

FIG. 1 illustrates the real-time processing of natural data x an entire real-time environment to be supported within the 

types. Natural data types require real-time response for graphical user interface. The scheduler of the real-time 

presenution and capture. Tne audio and video data must be kernel supports multiple threads of execution all running at 

transmitted to and from external output devices in a timely higher priority than the graphical user interface tasks By 

manner. In step 10, data from an audio/video file on disk is using synchronization mechanisms of the graphical user 

read to a memory buffer. The memory buffer is then trans- 35 interface, e.g. VxD events in enhanced mode Windows®, 

ferred to a playback device by an interrupt service routine in the real-time tasks are able to make use of system services 

step 12, in response to hardware interrupts by the playback 0 f the graphical user interface. 

t * n a. • . - . L * The method and apparatus of the present invention allows 

In step 14, the mtem.pt service routine signal* the task to real . lime programming with support for the presentation^ 

? m J^F^^"^ m £? a V'V am ' « MtUMl *»* types, vdthout altowing other operations to 

^T^^f^-t^, to ^!^ U ^ re4dSm ? re ^ *» "1 Pbybackof the audiTand v?d£ 

data torn the audw/vKieo fik on disk. If mere is excessive dato . ^ metbod ^ ^ of me k 

delay in the data transfer from the memory buffer to the ^ applied m coinmuricauons. 
playback device or from disk to the memory buffer, a tl . ■ ^ , . 
nodceablechckorapopmrneplaybackofthrLdioMdeo 45 J^^^T 0 ^ Tv* 8 • me,bod 
data is produced. Such delay is called interrupt and/or a task ^"T to l**'<™?& at mterrupt tune 
latency. Interrupt latency is' the delay between . hardware S^SllSSS.S ^"TV '° ^ l ° 
interrupt signal and the execution of the first instruction of *Tf?" d 5. mb ?* ^,en, l • lisk f ™ «■*» « soon 
an interrupThndkr. Task latency is the delay between a ? \ Sl8Dtbae m , te ™ pl ^pletes, rather than wait- 
highest priority task becoming ready for execution and „ ^f/l?'^ 1 '? ^ emboiment improves 
actually beginning execution real-time response. In situations where real-time tasks must 
. i7 . . , .... use VxD services, the present invention provides a method 

A t^r^ Wra ; andapparatusforensur^ 

dows® OVindows® ,s a registered trademark of Nhcrosoft safe for VxD 

Corporauon of Redmond, Wash.), if audio or video playback - m f ^ - # . , 

alone is being executed, a system processing the natural data 55 J^? 8 " of the present invention will become 

types willTroduce a smooth playback output. However. ft™* " *~ d m * c » d " ** 

other operations being performed on a system processing the f ° lloWmg dcU,lcd dcscn P Uon * P^fened embodiment, 

natural data types, such as spreadsheet and networking BRIEF DESCRIPTION OF THE DRAWINGS 
activities, as well as transmission of electronic mail 

(E-mail), can disrupt the scheduling of the audio and video « FIG * 1 iUuslrates real-time processing of natural data 

playback. Such disruptions may cause the audio and video i YP es ' 

playback to manifest pops, clicks and/or jerky video output. HG. 2 programming environments in Windows®. 

In addition, playback of both audio as well as video data may FIG. 3 illustrates real-time interrupt handling and task 

produce an unnatural output due to lack of synchronization scheduling in a VxD environment. 

of the natural data types. 65 FIGS. 4S are flowcharts illustrating the processing flow 

It is desirable to have a method and apparatus for allowing of the preferred embodiment, 

real-time programming with support for the presentation of FIG. 9 illustrates the cxecution modes of an RT task. 
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DETAILED DESCRIPTION OF THE of the calling thread with the idle task. RT scheduler 30 then 
INVENTION returns to VxD initialization code 38. Al this point there is 
An improved method and apparatus for embedding a a sm # c lask » mc icfic Uslt » wi^m toe real-time environment, 
real-time multi-tasking kernel in a non-real-time operating Initialization code 38 may then create other, application- 
system is disclosed The present invention utilizes the VxD 5 specific tasks. For example, initialization code 38 may create 
environment in Windows® to provide real-time interrupt a task to perform capture or playback of audio/video, 
handling and task scheduling for personal computer appli- Because such application-specific tasks are higher priority 
cations dealing with communications and natural data types. than the idle task, scheduler 30 will prempt the idle task in 
FIG. 2 illustrates a Windows® VxD programming envi- ordcr to execute another task as soon as it is created. Each 
ronment as a preferred embodiment of the present invention. 10 ^PP^^tion-specific task performs initialization of its appli- 
CPU 19 of computer 18 controls the operations of: system cation when it starts. The example task might initialize its 
virtual machine 20, a set of DOS virtual machines 24, virtual audio/video device, including installing RT interrupt handler 
machine manager (VMM) 26, and a set of virtual device ^2, to sery i ce ue device. The example task might also install 
drivers (VxDs) 28. Windows® applications 22, including another RT interrupt handler to service software interrupts, 
dynamic link libraries execute in system virtual machine 20. 15 generated by Windows® applications wishing to communi- 
In the system virtual machine environment, applications are 0316 toe application-specific task. Eventually, each 
scheduled in a cooperative multi-tasking manner. Because of application specific task will complete initialization, and 
the cooperative nature of the scheduling mechanism, real- block. For instance, the example application would block 
time response cannot be guaranteed for any given applica- waiting for the audio/video device to complete an operation 
tion. 20 or wr 4 Windows® application to communicate with the 
In contrast, DOS virtual machines 24, and system virtual ^ When applicauon-specific tasks complete execution 
machine 20 in it's entirety, are scheduled preemptively by block > mc i<fle ^ wiu executed. Hie idle task 
enhanced mode VMM 26: Although the scheduling of executes VxD initialization code 38, which then returns to 
virtual machines is preemptive, VMM 26 emphasizes user „ VMM 26 ' At lhis P° ml toe cmirc real-time environment 28, 
responsiveness, rather than the real-time response require- eluding all its tasks has initialized. VMM 26 may now 
ments of particular virtual machines. As a result, the DOS complete initialization of the rest of the system, allowing the 
virtual machine environment 24 does not provide satisfac- computer to begin normal operation, 
tory real-time response for natural data type processing, FIG. 3 illustrates the sequence of events for the present 
although it does provide better response than the cooperative invention during normal system operation. References will 
environment in which Windows® applications are sched- be made to elements described in FIG. 2. Virtual Machine 
uled. (VM) mode 40 represents the phase of system operation 
The virtual device driver (VxD) environment of when virtual machines arc executing. VM mode 40 includes 
Windows®, supported by VMM 26, provides sufficient the execution of both DOS virtual machines 24 and system 
interrupt response for communications and natural data type 35 v ^ rtua ^ machine 22, in which Windows® applications 
processing. VxDs are thirty-two bit dynamic link libraries execute. VxD event mode 50 represents the phase of system 
running at the most privileged level (ring 0) of CPU 19. The operation when the VMM 26 executes events. In particular, 
VxD environment, however, is totally interrupt-driven. Y* 0 event moc *e 50 represents the time when RT event 36 
There is no notion of tasks or task scheduling in this * executing. VxD interrupt mode 60 represents the phase of 
environment. Because of this, the standard VxD environ- ^ s y stem operation when VMM 26 or VxD interrupt handlers 
ment is very difficult to use for communications or natural ^ executing. In particular, interrupt mode 60 represents the 
data type processing. The present invention presents a umc when RT interrupt handlers 32 are executing, 
method for embedding a real-time scheduler into a VxD, in Normally, the system will be executing within a virtual 
order to provide real-time multi-tasking for communication machine, either a DOS VM or the system virtual machine, 
and natural data type applications. 45 VMM 26 schedules virtual machines, and the Windows® 
The method of the present invention for supporting real- kernel schedules Windows® applications within the system 
time multi-tasking consists of VxD 28, containing real-time VM, all without any knowledge of RT scheduler 30. RT 
scheduler (RT scheduler) 30, application specific interrupt scheduler 30 remains inactive, with its state indicating that 
handlers 32, real-time tasks (RT Tasks) 34, event 36, and the idle task is running and all other RT tasks 34 and 35 are 
VxD initialization code 38. One of the real-time tasks, 50 asleep. 

referred to as an idle task, is dedicated to context switching At some point, an interrupt occurs which causes the 

between Windows® and real-time VxD, and has the lowest processor to switch to VxD interrupt mode 60 and execute 

priority of any task scheduled by real-time scheduler 30. RT interrupt handler 32. For the example application it is 

A real-time scheduler 30. for use in the present inveotion assumed that the hardware interrupt handler servicing the 
has three capabilities. Fust, it is capable of scheduling tasks 55 audio/video device is invoked. (Operation is identical for the 

preemptively by priority. Secondly, the real-time scheduler case of a software interrupt from a Windows® application.) 

30 allows interrupt handlers 32 to make real-time tasks 34 As part of servicing the interrupt, RT interrupt handler 32 

ready for execution without preemption occurring (i.e., it may need to wake up its associated real-time task. For 

supports a scheduling lock). Thirdly, the real-time scheduler example, the audio/video device may have completed filling 
30 allows the scheduling lock to be released causing any 60 a buffer with data which the task needs to process, 

high priority, ready real-time tasks to prempt the current As shown in FIG. 3, RT interrupt handler 32, once 

process. activated by a hardware interrupt, stops RT scheduler 30 to 

Initialization of this environment proceeds as follows: prevent RT scheduler 30 from switching tasks while the 

VxD initialization code 38 is invoked by VMM 26 during real-time interrupt is being handled. RT interrupt handler 32 
system initialization. This initialization code 38 invokes the 65 wakes up the RT task associated with the hardware interrupt 

initialization entry point of RT scheduler 30. In response, RT RT interrupt handler 32 then starts RT scheduler 30. As a 

scheduler 30 creates an idle task and associates the context result, the previously awakened RT task starts execution 
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FIG. 3 illustrates two basic types of RT tasks supported by Referring now to FIG. 6, processing logic for the Mike_ 

the present invcotion. The first type of RT task 34 represents Safe procedure is illustrated starting at bubble 610. The 

an RT task which does not require calls to VM services as Make_£afe procedure first schedules RT event 36 to signal 

part of the RT task execution. Because these types of RT a semaphore when the execution environment is safe 
tasks do not employ VM services, there is no danger in $ (processing block 612). The processing logic for the RT 

executing these types of tasks solely in interrupt mode 60 as event is illustrated in FIG. 7. 

shown in FIG. 3. Thus, once RT interrupt handler 32 starts Referring now to FIG. 7, RT event processing is shown 
RT scheduler 30, RT task 34 immediately begins execution starting at bubble 710. Because the RT event 36 is scheduled 
and continues execution to completion in interrupt mode 60. with the virtual machine manager, the RT event executes in 
Once completed, RT task 34 returns, RT interrupt handler 32 event mode 50. Once VMM 26 activates RT event 36, no 
returns, and servicing for the hardware interrupt is complete. recursive call problems exist and the execution environment 
The second type of RT task supported by the present for the RT task is safe. Thus, RT event 36 simply signals a 
invention is illustrated in FIG. 3 as RT task portion 35 and semaphore in processing block 712 to enable the remaining 
RT task portion 37. RT task portion 35 and RT task portion portion 37 of RT task 2. RT event mode processing then 
37 together represent an RT task 2 which requires the use of returns through bubble 714 illustrated in FIG. 7. 
VM services as part of RT task execution. As well known to 15 Referring again to FIG. 6, Make_Safe processing waits 
those of ordinary skill in the art, it is not safe to execute a for the completion of RT event 36 by waiting for the 
VM call from interrupt mode 60. VM calls may fail if semaphore to be signaled in decision block 614. Once this 
recursively called from interrupt mode 60. For this reason, occurs, processing path 618 is taken to processing block 
it is necessary to be in event mode 50 when the VM service ^ 620. In this case, the RT task portion 37 is executed from 
call is executed. In the present invention, therefore, the RT event mode. Until the semaphore is signalled (decision 
task 2 is split into an interrupt mode processing portion 35 block 614), the RT task is actually asleep in a dormant mode, 
and an event mode processing portion 37 as illustrated in No polling of the semaphore is necessary. 
HG. 3. Referring now to FIG. 8, processing logic for the RT task 
When RT interrupt handler 32 starts RT scheduler 30, RT ^ portion 37 is illustrated starting at bubble 810. This pro- 
task portion 35 immediately begins execution in interrupt cessing logic is a continuation from block 514 illustrated in 
mode 60. Any portion of RT task 2 not requiring VM service FIG. 5. The RT task portion 37 executes from event mode, 
calls may be executed in RT task portion 35 in interrupt Because it has been previously determined that the execu- 
mode. When it is necessary to execute a VM call, RT task tion environment is safe, a VM call (or calls) is executed in 
portion 35 schedules execution of RT event 36 with the x processing block 812. Other portions of the processing for 
virtual machine manager. RT task portion 35 then blocks on the RT task are performed in event mode in processing block 
a semaphore and waits for the execution of RT event 36. 814. Once the event mode processing for the interrupt is 
After a small delay, RT event 36 begins execution in event complete, the RT task goes to sleep in decision block 818 
mode 50. RT event 36 signals the semaphore and returns waiting for the next interrupt When the interrupt occurs 
thereby enabling RT task portion 37 to continue execution in 35 (processingpath 822), the process starts over again at bubble 
event mode 50. Because the execution environment for RT 510 shown in FIG. 5 and described below, 
task 2 has been made safe by the execution of RT event 36, Referring now to FIG. 9, the RT task execution environ- 
RT task portion 37 may now execute a VM service call in ments are illustrated. For an RT task requiring use of VM 
event mode 50. RT task portion 37 may execute one or more service calls, the RT task comprises an interrupt mode 
VM calls. Other event mode processing for RT task 2 may ^ environment and an event mode environment The interrupt 
be performed by RT task portion 37. Upon completion, RT mode environment is initially entered through RT interrupt 
task portion 37 returns thereby completing processing for handler 32. When it is necessary to execute a VM call, an RT 
the hardware interrupt. event is scheduled by Make_Safe through the 'virtual 
Referring now to FIG. 4, the processing logic for RT task machine manager. Once this RT event begins execution, the 
1 begins a bubble 410. This processing logic corresponds to 45 event mode environment of the RT task is entered by means 
RT task 34 illustrated in FIG. 3. Because RT task 1 does not of the semaphore signalled by Make_Safe as shown by 
perform VM calls, the hardware interrupt is handled com- arrow 910 illustrated in FIG. 9. From event mode, the VM 
pletcly in interrupt mode in processing block 412. Once the call is executed along with any additional event mode 
interrupt is handled, the RT 1 interrupt mode task goes to processing required by the RT task. The RT task then blocks 
sleep at decision block 413 waiting for the next interrupt 50 waiting for another interrupt signal, 
signal to occur. RT tasks will perform whatever processing is appropriate 
FIGS. 5-8 illustrate the processing logic for an RT task for a particular interrupt In the example, RT task 34, 35, or 
that requires VM calls during RT task execution. Such an RT 37 would process the audio/video data captured by the 
task is represented in FIG. 3 as RT task 2 comprising RT task audio/video device. As part of its execution, RT tasks may 
portion 35 and RT task portion 37. RT task portion 35 55 awaken other RT tasks causing them to execute in turn, 
processing logic is illustrated in FIG. 5. Eventually, all RT tasks complete their processing, and block 
Referring now to FIG. 5, RT task portion 35 processing waiting for another signal to trigger their execution. Al this 
logic in interrupt mode is shown starting at bubble 510. RT point, the idle task regains control. The idle task returns the 
task interrupt mode processing continues until a VM call is system to VM mode 40 to resume normal system operation, 
necessary as part of RT task execution (processing block 60 This completes the cycle. Windows® schedulers 41 are 
512). Because it is not safe to execute the VM call from back in control, all RT tasks axe blocked, and RT scheduler 
interrupt mode, separate processing is required to perform 30 believes the idle task is executing. Another interrupt starts 
the VM call from the event mode execution environment. In the cycle all over again. It is clear that the implementation 
the preferred embodiment, a procedure called Make_Safe is detail is readily apparent to one skilled in the art based upon 
called to create a safe execution environment for the VM call 65 the detailed and operational description herein, 
(processing block 514). The processing logic for the Make_ An important property of the present invention is that RT 
Safe procedure is illustrated in FIG. 6. tasks execute with less delays in primarily the interrupt 
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mode. Id some circumstances (i.e. when VM services are not 
required), the RT task executes very quickly from purely the 
interrupt mode. In other circumstances when VM services 
are required, the RT task can execute partially in interrupt 
mode and partially in VxD event mode. Because event mode 5 
has precedence over all Windows® applications and DOS 
virtual machines, RT tasks are free of the scheduling prob- 
lems caused by them. On the other hand, RT tasks executing 
in event mode are free to take advantage of all services 
provided by the VMM. Thus, RT tasks in this invention 10 
execute with less delay in the interrupt mode; yet, they arc 
not subject to the substantial restrictions placed on VxD 
interrupt mode. In effect, the present invention improves 
real-time response by delaying the scheduling of events until 
necessary. In the invention of the above- referenced is 
co-pending patent application, the invention always sched- 
uled an event before a real-time task executed. The present 
invention schedules an event only when it is needed to safely 
use a VxD service. It should be noted, however, that the 
preferred embodiment does not support time slicing sched- 20 
ulers or functions which dynamically re -arrange task priori- 
ties. 

What has been described is an improved method and 
apparatus for embedding a real-time multi-tasking kernel in 
a non-real-time operating system. Through use of the VxD 25 
programming environment, the present invention supports 
real time scheduling of real-time tasks involving the pro- 
cessing of communications and natural data types. 

While certain exemplary embodiments have been 
described in detail and shown in the accompanying 30 
drawings, it is to be understood that such embodiments are 
merely illustrative of and not restrictive on the broad 
invention, and that this invention not be limited to the 
specific arrangements and constructions shown and 
described, since various other modifications may occur to 35 
those of ordinary skill in the art 

What is claimed is: 

1. A method for using events in a non-real time operating 
system to support real-time programming, said method 
comprising the steps of: 

running real-time tasks in a VxD environment; 

using VxD events within the non-real time operating 
system to make VxD services available for use by said 
real-time tasks; 45 

embedding a real-time scheduler in said VxD environ- 
ment; 

enabling multi-tasking using said real-time scheduler in 
said VxD environment, said real-time scheduler sched- 
uling said real-time events to execute when needed; and 50 

executing real-time tasks partially in an interrupt mode 
and partially in an event mode, based on when said 
real-time tasks are needed. 

2. The method of claim 1 further comprising the step of: 
creating real-time tasks to handle communication or natu- 
ral data types captured or processed for a playback. 

3. The method of claim 1 further comprising the step of 
causing a processor to switch from executing in a virtual 
machine to executing in a VxD interrupt mode, said step M 
performed by a virtual machine manager. 

4. The method of claim 3 further comprising the step of 
performing a hardware interrupt to indicate an audio/video 
capture. 

5. The method of claim 3 further comprising the step of 65 
performing an application call to indicate an audio/video 
playback 



8 



40 



55 



6. The method of claim 3 further comprising the steps of: 
entering said VxD environment; 
executing a real-time interrupt handler in said VxD envi- 
ronment in said VxD interrupt mode; 

entering VxD event mode and executing said VxD event; 
and 

returning to said virtual machine manager and resuming 
normal operation in said virtual machine. 

7. A system for using events in a non-real time operating 
system to support real-time programming, said system com- 
prising: 

a processor executing real-time tasks in a VxD environ- 
ment; 

a real-time scheduler embedded in a VxD environment, 
said real-time scheduler enabling multi-tasking and 
using VxD events within the non-real time operating 
system to make VxD services available for use by said 
real-time tasks, said real-time scheduler also schedul- 
ing said real-time events to execute when needed; and 
means for executing said real-time tasks partially in an 
interrupt mode and partially in an event mode, based on 
when said real-time tasks are needed. 

8. The system of claim 7 further comprising: 
real-time tasks to handle communication or natural data 

types captured or processed for a playback. 

9. The system of claim 7 further comprising a virtual 
machine manager for causing a processor to switch from 
executing in a virtual machine to executing in a VxD 
interrupt mode. 

10. The system of claim 9 further comprising a hardware 
interrupt to indicate an audio/video capture. 

U. The system of claim 9 further comprising means for 
performing an application call to indicate an audio/video 
playback. 

12. The system of claim 9 further comprising: 
means for entering said VxD environment; 
a real-time interrupt handler executing in said VxD envi- 
ronment in said VxD interrupt mode; 

means for entering VxD event mode and executing said 

VxD event; and 
means for returning to said virtual machine manager and 
resuming normal operation in said virtual machine. 

13. A method for using events in a non-real time operating 
system to support real-time programming comprising: 

receiving a hardware interrupt related to a real-time task 

in virtual machine mode; 
executing a real-time interrupt handler in an interrupt 
mode of a VxD environment to process the interrupt; 
determining whether the interrupt requires virtual 
machine services; 

processing interrupt handling tasks that do not require the 
virtual machine services in the interrupt mode of the 
VxD environment; and 
processing interrupt handling tasks that require the virtual 
machine services in an event mode of the VxD envi- 
ronment with a virtual machine manager. 

14. The method of claim 13, further comprising: 
returning to the interrupt mode of the VxD environment; 

and 

returning to the virtual machine mode. 
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